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Abstract 

This specification defines the HyperText Markup Language (HTML), version 4.0, the publishing language of the 
World Wide Web. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML, 
HTML 4.0 supports more multimedia options, scripting languages, style sheets, better printing facilities, and 
documents that are more accessible to users with disabilities. HTML 4.0 also takes great strides towards the 
internationalization of documents, with the goal of making the Web truly World Wide. 

HTML 4.0 is an SGML application conforming to International Standard ISO 8879 - Standard Generalized Markup 
Language [ISQ8879] . 



This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director 
as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative 
reference from another document. W3C's role in making the Recommendation is to draw attention to the specification 
and to promote its widespread deployment. This enhances the functionality and interoperability of the Web. 

W3C recommends that user agents and authors (and in particular, authoring tools) produce HTML 4.0 documents 
rather than HTML 3.2 documents (see [HTML32] V For reasons of backwards compatibility, W3C also recommends 
that tools interpreting HTML 4.0 continue to support HTML 3.2 and HTML 2.0 as well. 

A list of current W3C Recommendations and other technical documents can be found at http ://www. w3 . org/TR . 
Public discussion on HTML features takes place on www-html @, w3 . org . 

This document is a revised version of the document first released on 18 December 1997. Changes from the ori ginal 
version are only editorial in nature. A 
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17 Forms 



Contents 

1. Introduction to forms 

2. Controls 

1. Control types 

3. The form element 

4. The input element 

1. Control types created with INPUT 

2. Examples of forms containing INPUT controls 

5. The button element 

6. The select, optgroup. and option elements 

1. Preselected options 

7. The textarea element 

8. The is index element 

9. Labels 

1. The label element 

10. Adding structure to forms: the fieldset and legend elements 

11. Giving focus to an element 

1. Tabbing navigation 

2. Access keys 

12. Disabled and read-only controls 

1. Disabled controls 

2. Read-only controls 

13. Form submission 

1. Form submission method 

2. Successful controls 

3. Processing form data 

■ Step one: Identify the successful controls 

■ Step two: Build a form data set 

■ Step three: Encode the form data set 

■ Step four: Submit the encoded form data set 

4. Form content typ es 

■ appl i cati on/x-www-form-urlencoded 

■ multipart/form -data 



17.1 Introduction to forms 

An HTML form is a section of a document containing normal content, markup, special elements called controls 
(checkboxes, radio buttons, menus, etc.), and labels on those controls. Users generally "complete" a form by modifying 
its controls (entering text selecting menu items, etc.), before submitting the form to an agent for processing (eg to a 
Web server, to a mail server, etc.) 

Here's a simple form that includes labels, radio buttons, and push buttons (reset the form or submit it): 
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<FORM action="http://somesite.com/prog/adduser M method="post M > 
v <P> 

< LABEL for= M firstname">First name: </LABEL> 

<INPUT type= ,, text" id="f irstname"><BR> 
< LABEL .for= M lastname">Last name: </LABEL> 

<INPUT type= M text" id="lastname"><BR> 
< LABEL for="email">email: </LABEL> 

<INPUT type="text" id="email "><BR> 
<INPUT type="radio" name="sex" value="Male n > Male<BR> 
<INPUT type="radio" name="sex" valuer" Female "> Female<BR> 
<INPUT type="submit" value="Send"> <INPUT type="reset"> 
</P> 
</FORM> 

Note. This specification includes more detailed information about forms in the subsections on form display issues . 

17.2 Controls 

Users interact with forms through named controls. 

A control's "control name" is given by its name attribute. The scope of the name attribute for a control within a form 
element is the form element. 



Each control has both an initial value and a current value, both of which are character strings. Please consult the 
definition of each control for information about initial values and possible constraints on values imposed by the control 
In general, a control's Initial value" may be specified with the control element's value attribute. However, the initial 
value of a textarea element is given by its contents, and the initial value of an object element in a form is determine* 
by the object implementation (i.e., it lies outside the scope of this specification). 

The control's "current value" is first set to the initial value. Thereafter, the control's current value may be modified 
through user interaction and scripts. 

A control's initial value does not change. Thus, when a form is reset, each control's current value is reset to its initial 
value. If a control does not have an initial value, the effect of a form reset on that control is undefined. 

When a form is submitted for processing, some controls have their name paired with their current value and these pairs 
are submitted with the form. Those controls for which name/value pairs are submitted are called successful controls . 

17.2.1 Control types 

HTML defines the following control types: 
buttons 

Authors may create three types of buttons: 

• submit buttons: When activated, a submit button submits a form. A form may contain more than one 
submit button. 

• reset buttons: When activated, a reset button resets all controls to their initial values. 

• push buttons: Push buttons have no default behavior. Each push button may have client-side scripts 
associated with the element's event attributes. When an event occurs (e.g., the user presses the button, 
releases it, etc.), the associated script is triggered. 

Authors should specify the scripting language of a push button script through a default script declaration 
(with the meta element). 
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Authors create buttons with the button element or the input element. Please consult the definitions of these 
elements for details about specifying different button types. 

Note. Authors should note that the button element offers richer rendering capabilities than the input 
element 



checkboxes 

Checkboxes (and radio buttons) are on/off switches that may be toggled by the user. A switch is "on" when the 
control elements selected attribute is set. 



When a form is submitted, only "on" checkbox controls can become successful . Several checkboxes in a form 
may share the same control name. Thus, for example, checkboxes allow users to select several values for the 
same property. The input element is used to create a checkbox control. 

radio buttons 

Radio buttons are like checkboxes except that when several share the same control name , they are mutually 
exclusive: when one is switched "on", all others with the same name are switched "ofT. The input element is 
used to create a radio button control, 
menus 

Menus offer users options from which to choose. The select element creates a menu, in combination with the 
optgroup and option elements, 
text input 

Authors may create two types of controls that allow users to input text. The input element creates a single-line 
input control and the textarea element creates a multi-line input control. In both cases, the input text becomes 
the control's current value , 
file select 

This control type allows the user to select files so that their contents may be submitted with a form. The input 
element is used to create a file select control, 
hidden controls 

Authors may create controls that are not rendered but whose values are submitted with a form. Authors generally 
use this control type to store information between client/server exchanges that would otherwise be lost due to the 
'stateless nature of HTTP (see [RFC2068] V The input element is used to create a hidden control, 
object controls 

Authors may insert generic objects in forms such that associated values are submitted along with other controls. 
Authors create object controls with the object element. 

The elements used to create controls generally appear inside a form element, but may also appear outside of a form 
element declaration when they are used to build user interfaces. This is discussed in the section on intrinsic events. 
Note that controls outside a form cannot be successful controls . 



17.3 The form element 



<! ELEMENT FORM ( %block; [SCRIPT) + -(FORM) — interactive form 



< ! ATTLIST FORM 
%attrs; 
action 



%URI; 

(GET | POST) 
%ContentType; 
%Script; 
%Script; 
accept-charset %Charsets; 
> 



method 
enctype 
onsubmit 
onreset 



— %coreattrs , %i!8n / %events — 
#REQUIRED — server-side form handler — 
GET — HTTP method used to submit the form- 

"application/x-www-form-urlencoded" 
#IMPLIED — the form was submitted — 
#IMPLIED — the form was reset — 
#IMPLIED — list of supported charsets — 



Start tag: required, End tag: required 
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Attribute definitions 



action = uri TCT1 

This attribute specifies a form processing agent. For example, the value might be a HTTP URI (to submit the 
form to a program) or a mailto URI (to email the form). 

method = get | post [CI] 

This attribute specifies which HTTP method will be used to submit the form data set . Possible (case-insensitive) 
values are "get" (the default) and "post". See the section on form submission for usage information, 
enctype = content-type [CI] 

This attribute specifies the content type used to submit the form to the server (when the value of method is 
"post"). The default value for this attribute is "application/x-www-form-urlencoded". The value "multipart/form- 
data" should be used in combination with the input element, type- Tile". 

accept-charset = char set list [CI] 

This attribute specifies the list of character encoding s for input data that must be accepted by the server 
processing this form. The value is a space- and/or comma-delimited list of charset values. The server must 
interpret this list as an exclusive-or list, i.e., the server must be able to accept any single character encoding per 
entity received. 

The default value for this attribute is the reserved string "UNKNOWN". User agents may interpret this value as 
the character encoding that was used to transmit the document containing this form element. 

accept = content-tvpe-list [CI] 

This attribute specifies a comma-separated list of content types that a server processing this form will handle 
correctly. User agents may use this information to filter out non-conforming files when prompting a user to selec 
files to be sent to the server (cf the input element when type ="file"). 

Attributes defined elsewhere 

• id, class ( document-wide identifiers ) 

• lanq (language information ! dir (text direction ) 

• style ( inline style information ) 

• title (element title ) 

• target ( target frame information) 

• onsubmit. onreset , onclick, ondblclick . onmousedown . onmouseup. onmouseover . onmousemove . 
onmouseout. onkeypress . onkeydown . onkevup ( intrinsic events ) 

The form element acts as a container for controls . It specifies: 

• The layout of the form (given by the contents of the element). 

• The program that will handle the completed and submitted form (the action attribute). The receiving program 
must be able to parse name/value pairs in order to make use of them. 

• The method by which user data will be sent to the server (the method attribute). 

• A character encoding that must be accepted by the server in order to handle this form (the accept-charset 
attribute). User agents may advise the user of the value of the accept-charset attribute and/or restrict the user's 
ability to enter unrecognized characters. 

A form can contain text and markup (paragraphs, lists, etc.) in addition to form controls. 

The following example shows a form that is to be processed by the "adduser" program when submitted. The form will 
be sent to the program using the HTTP "post" method. 

<FORM action="http: //somesite . com/prog/adduser" method= ,r post "> 
. . .form contents . . . 
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</FORM> 

The next example shows how to send a submitted form to an email address: 

<FORM action="mailto: Kligor.T@gee.whiz.com" method= ,f post"> 

. . . form contents . . . 

</FORM> 

Please consult the section on form submission for information about how user agents must prepare form data for 
servers and how user agents should handle expected responses. 

Note. Further discussion on the behavior of servers that receive form data is beyond the scope of this specification. 

17o4 The input efleinienit 

<! ENTITY % InputType 

" (TEXT | PASSWORD | CHECKBOX | 
RADIO | SUBMIT | RESET | 
FILE | HIDDEN | IMAGE | BUTTON) " 

> 



<! — attribute name required for all but 
<! ELEMENT INPUT - 0 EMPTY 
< ! ATTLIST INPUT 



%attrs; 








type 


% InputType; 


TEXT 




name 


CDATA 


#IMPLIED 




value 


CDATA 


#IMPLIED 




checked 


(checked) 


#IMPLIED 




disabled 


(disabled) 


#IMPLIED 




readonly 


(readonly) 


#IMPLIED 




size 


CDATA 


#IMPLIED 




maxlenqth 


NUMBER 


#IMPLIED 




src 


%URI; 


#IMPLIED 




alt 


CDATA ■ 


#IMPLIED 




u semap 


%URI ; 


#IMPLIED 




tabindex 


NUMBER 


#IMPLIED 




accesskey 


%Character; 


#IMPLIED 




onf ocus 


%Script; 


#IMPLIED 




onblur 


%Script; 


#IMPLIED 




onselect 


%Script; 


#IMPLIED 




onchanqe 


%Script; 


#IMPLIED 




accept 


%ContentTypes; 


#IMPLIED 





> 



submit & reset — > 
form control — > 

%coreattrs , %i!8n / %events — 

what kind of widget is needed — 

submit as part of form — 

required for radio and checkboxes — 

for radio buttons and check boxes — 

unavailable in this context — 

for text and passwd — 

specific to each type of field — 

max chars for text fields — 

for fields with images -- 

short description — 

use client-side image map — 

position in tabbing order — 

accessibility key character — 

the element got the focus — 

the element lost the focus — 

some text was selected — 

the element value was changed — 

list of MIME types for file upload — 



Start tag: required, End tag: forbidden 
Attribute definitions 

type = text | password | checkbox | radio | submit | reset | file | hidden | image | button [CI] 

This attribute specifies the type of control to create. The default value for this attribute is "text", 
name = cdata [CI] 

This attribute assigns the control name , 
value = cdata [CA] 

This attribute specifies the initial value of the control It is optional except when the type attribute has the value 
"radio", 
size = cdata [CN] 
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This attribute tells the user agent the initial width of the control. The width is given in pixels except when type 
attribute has the value "text" or "password". In that case, its value refers to the (integer) number of characters, 
maxiength = number [CN] 

When the type attribute has the value "text" or "password", this attribute specifies the maximum number of 
characters the user may enter. This number may exceed the specified size , in which case the user agent should 
offer a scrolling mechanism. The default value for this attribute is an unlimited number. 

checked [CI] 

When the type attribute has the value "radio" or "checkbox", this boolean attribute specifies that the button is on 
User agents must ignore this attribute for other control types, 
src - uri [CT] 

When the type attribute has the value "image", this attribute specifies the location of the image to be used to 
decorate the graphical submit button. 

Attributes defined elsewhere 

• id, class (document-wide identifiers ) 

• lanq (language information ), dir (text direction ) 

• title ( element title ) 

• style (inline style information ) 

• ait (alternate text ) 

• align (alignment ) 

• accept (legal content types for a server ) 

• readonly ( read-only input controls ) 

• disabled ( disabled input controls ) 

• tabindex ( tabbing navigation ) 

• accesskey ( access keys ) 

• usemap (client-side image maps ) 

• onfocus . onblur . onselect . onchanqe T onclick , ondblclick . onmousedown . onmouseup T onmouseover . 
onmousemove , onmouseout . onkeypress . onkeydown . onkeyup ( intrinsic events ) 

17.4.1 Control types created with INPUT 

The control type defined by the input element depends on the value of the type attribute: 
text 

Creates a single-line text input control, 
password 

Like "text", but the input text is rendered in such a way as to hide the characters (e.g., a series of asterisks). This 
control type is often used for sensitive input such as passwords. Note that the current value is the text entered by 
the user, not the text rendered by the user agent. 

Note. Application designers should note that this mechanism affords only light security protection. Although 
the password is masked by user agents from casual observers, it is transmitted to the server in clear text, and 
may be read by anyone with low-level access to the network 

checkbox 

Creates a checkbox. 

radio 

Creates a radio button. 
submit 

Creates a submit button. 

image 
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Creates a graphical submit button. The value of the src attribute specifies the URI of the image that will decorat* 
the button. For accessibility reasons, authors should provide alternate text for the image via the ait attribute. 



When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to 
the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of 
the image. The submitted data includes name.x=x-value and name .y=y-value where "name" is the value of the 
name attribute, and x-value andy-value are the x and y coordinate values, respectively. 

If the server takes different actions depending on the location clicked, users of non-graphical browsers will be 
disadvantaged. For this reason, authors should consider alternate approaches: 

• Use multiple submit buttons (each with its own image) in place of a single graphical submit button. 
Authors may use style sheets to control the positioning of these buttons. 

• Use a client-side image map together with scripting. 

reset 

Creates a reset button. 
button 

Creates a push button. User agents should use the value of the value attribute as the button's label, 
hidden 

Creates a hidden control. 

file 

Creates a file select control. User agents may use the value of the value attribute as the initial file name. 
17.4.2 Examples of forms containing INPUT controls 

The following sample HTML fragment defines a simple form that allows the user to enter a first name, last name, emai 
address, and gender. When the submit button is activated, the form will be sent to the program specified by the action 
attribute. 



<FORM action="http: //somesite. com/prog/ adduser" method="post"> 
<P> 

First name: <INPUT type="text" name="f irstname"XBR> 
Last name: <INPUT type= M text" name= M lastname"XBR> 
email: <INPUT type="text" name= ,, email ,, XBR> 
<INPUT type="radio" name="sex" value="Male"> Male<BR> 
<INPUT type= M radio" name="sex" value=" Female" > Female<BR> 
<INPUT type= ,, submit" value="Send"> <INPUT type="reset "> 
</P> 
</FORM> 



This form might be rendered as follows: 
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In the section on the label element, we discuss marking up labels such as "First name". 

In this next example, the JavaScript function name verify is triggered when the "onclick" event occurs: 

<HEAD> 

<META http-equiv="Content-Script-Type" con'tent= M text/ j avascript"> 

</HEAD> 

<BODY> 

<FORM action=". . . " method= ,, post"> 
<P> 

<INPUT type="button" value= M Click Me" onclick="verif y ( ) "> 
</FORM> 
</BODY> 

Please consult the section on intrinsic events for more information about scripting and events. 
The following example shows how the contents of a user-specified file may be submitted with a form. The user is 
prompted for his or her name and a list of file names whose contents should be submitted with the form. By specifying 
the enctyp e value of "multipart/form-data", each file's contents will be packaged for submission in a separate section 
of a multipart document. 

<FORM action="http: //server . dom/cgi/ handle" 
enctype= "multipart/ form-data" 
method="pos t " > 

<P> 

What is your name? <INPUT type="text" name="name_of_sender"> 
What files are you. sending? <INPUT type="file" name="name_of_f iles"> 
</P> 
</FORM> 



17,5 The button element 



<! ELEMENT BUTTON - - 

( %flow; ) * - (A| %formctrl; 
— push button — > 
< ! ATTLIST BUTTON 
%attrs; 



FORM | FIELDSET) 



value 

type 

disabled 
tabindex 
accesskey 
onf ocus 
onblur 



CDATA 
CDATA 

(button] submit | 
(disabled) 
NUMBER 
%Character; 
%Script; 
%Script; 



#IMPLIED 
#IMPLIED — 
reset ) submit 
#IMPLIED 
#IMPLIED 
#IMPLIED 
#IMPLIED 
#IMPLIED 



%coreattrs / %i!8n , %events — 

sent to server when submitted 
— for use as form button — 
unavailable in this context — 
position in tabbing order — 
accessibility key character — 
the element got the focus — 
the element lost the focus — 



Start tag: required, End tag: required 
Attribute definitions 
name = cdata [CI] 

This attribute assigns the control name. 
value = cdata [CS ] 

This attribute assigns the initial value to the button. 

type = submit | button | reset [CI] 

This attribute declares the type of the button. Possible values: 

• submit : Creates a submit button. This is the default value. 

• reset : Creates a reset button. 
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• button: Creates a push button 



Attributes defined elsewhere 

• id, class ( document-wide identifiers ) 

• lang ( language information ! dir ( text direction ) 

• title ( element title ) 

• style (inline style information ) 

• disabled ( disabled input controls ) 

• accesskey ( access keys ) 

• tabindex ( tabbing navigation ) 

• onfocus , onblur , onclick , ondblclick , onmousedown , onmouseup , onmouseover , onmousemove , onmouseout , 
onkeypress , onkeydown , onkeyup ( intrinsic events ) 

Buttons created with the button element function just like buttons created with the input element, but they offer riche 
rendering possibilities: the button element may have content. For example, a button element that contains an image 
functions like and may resemble an input element whose type is set to "image", but the button element type allows 
content. 

Visual user agents may render button buttons with relief and an up/down motion when clicked, while they may render 
input buttons as a "flat" images. 

The following example expands a previous example, but creates submit and reset buttons with button instead of 
input . The buttons contain images by way of the img element. 

<FORM action="http: //somesite . com/prog/ adduser" method="post"> 
<P> 

First name: <INPUT type="text" name="f irstname"XBR> 
Last name: <INPUT type="text" name= " 1 a s t name " ><BR> 
email: <INPUT type="text" name="email"><BR> 
<INPUT type="radio" name="sex" value="Male"> Male<BR> 
<INPUT type="radio" name="sex" value="Female"> Female<BR> 
<BUTTON name=" submit" value=" submit" type=" submit "> 
Send<IMG src="/icons/wow.gif " alt="wow"x/BUTTON> 
< BUTT ON name="reset" type="reset"> 

Reset<IMG src="/icons/oops . gif " alt="oops"X/BUTTON> 
</P> 
</FORM> 

Recall that authors must provide alternate text for an img element. 

It is illegal to associate an image map with an img that appears as the contents of a button element. 



ILLEGAL EXAMPLE: 

The following is not legal HTML. 

<button> 

<IMG src="foo. gif " usemap=" . . . "> 
</BUTTON> 

--iiiinnnnniiii i] iiiiniin--ir-mTiniii in 1 1 i in i in^aii 1 1 n 1 1 1 imii iim n wwiwiww m iiiniimmmi t 

17.6 The select, optgroup, and option elements 

<! ELEMENT SELECT - - (OPTGROUP | OPTION) + — option selector — > 
< ! ATTLIST SELECT 
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onchange 


% Script; 


#IMPLIED 



— %coreattrs , %i!8n , %events — 

— field name — 

— rows visible — 

-- default is single selection — 

— unavailable in this context — 

— position in tabbing order — 

— the element got the focus — 

— the element lost the focus — 

— the element value was changed — 



Start tag: required, End tag: required 
SELECT Attribute definitions 
name = cdata [CI] 

This attribute assigns the control name. 
size = number [CN] 

If a select element is presented as a scrolled list box, this attribute specifies the number of rows in the list that 
should be visible at the same time. Visual user agents are not required to present a select element as a list box; 
they may use any other mechanism, such as a drop-down menu, 
multiple [CI] 

If set, this boolean attribute allows multiple selections. If not set, the select element only permits single 
selections. 

Attributes defined elsewhere 

• id, class (document-wide identifiers ) 

• lanq ( language information ! dir ( text direction ) 

• title (element title ) 

• style ( inline style information ) 

• disabled ( disabled input controls ) 

• tabindex ( tabbing navigation ) 

• onclick , ondblclick , onmousedown , onmouseup , onmouseover , onmousemove , onmouseout . onkeypress , 
onkeydown . onkeyup ( intrinsic events ) 

The select element creates a menu . Each choice offered by the menu is represented by an option element. A select 
element must contain at least one option element. 

The optgrqup element allows authors to group choices logically. This is particularly helpful when the user must 
choose from a long list of options; groups of related choices are easier to grasp and remember than a single long list of 
options. In HTML 4.0, all optgrqup elements must be specified directly within a select element (i.e., groups may not 
be nested). 

17.6.1 Preselected options 

Zero or more choices may be pre-selected for the user. User agents should determine which choices are pre-selected as 
follows: 

• If no option element has the selected attribute set, no options should be pre-selected. 

• If one option element has the selected attribute set, it should be pre-selected. 

• If the select element has the multiple attribute set and more than one option element has the selected 
attribute set, they should all be pre-selected. 

• It is considered an error if more than one option element has the selected attribute set and the select element 
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does not have the multiple attribute set. User agents may vary in how they handle this error, but should not pre- 
select more than one choice. 



<! ELEMENT OPTGROUP - - (OPTION) + — option group — > 

< ! ATTLIST OPTGROUP 

%attrs; — %coreattrs , %i!8n , %events — 

disabled (disabled) #IMPLIED — unavailable in this context — 

label %Text; #REQUIRED — for use in hierarchical menus — 

> 



Start tag: required, End tag: required 
OPTGROUP Attribute definitions 
label = text [ CS ] 

This attribute specifies the label for the option group. 
Attributes defined elsewhere 



• id, class (document-wide identifiers ) 

• lanq ( language information) , dir (text direction ) 

• title (element title ) 

• style ( inline style information ) 

• disabled ( disabled input controls ) 

• onfocus , onblur , onchange , onclick , ondblclick, onmou s edown , onmouseup. onmouseover ., onmousemove 
onmouseout , onkeypress , onkeydown , onkeyup ( intrinsic events ) 

Note. Implementors are advised that future versions of HTML may extend the grouping mechanism to allow for 
nested groups (i.e., optgroup elements may nest). This will allow authors to represent a richer hierarchy of choices. 



<! ELEMENT OPTION - O (# PCDATA) 
<! ATTLIST OPTION 
%attrs; 

selected (selected) #IMPLIED 
disabled (disabled) #IMPLIED 
label %Text; #IMPLIED 

value CDATA #IMPLIED 

> 



selectable choice — > 

— %coreattrs , %i!8n , %events — 

— unavailable in this context — 

— for use in hierarchical menus — 
-- defaults to element content — 



Start tag: required, End tag: optional 
OPTION Attribute definitions 
selected [CI] 

When set, this boolean attribute specifies that this option is pre-selected. 
value = cdata [CS] 

This attribute specifies the initial value of the control. If this attribute is not set, the initial value is set to the 
contents of the option element, 
label = text TCS] 

This attribute allows authors to specify a shorter label for an option than the content of the option element. 
When specified, user agents should use the value of this attribute rather than the content of the option element a 
the option label. 



Attributes defined elsewhere 
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• id, class ( document-wide identifiers ) 

• iang ( language information ), dir ( text direction) 

• title ( element title ) 

• style ( inline style information ) 

• disabled ( disabled input controls ) 

• onclick , ondblclick , onmousedown. onmouseup , onmouseover . onmousemove , onmouseout , onkeypress , 
onkeydown , onkeyup (intrinsic events ) 

When rendering a menu choice, user agents should use the value of the label attribute of the option element as the 
choice. If this attribute is not specified, user agents should use the contents of the option element. 

The label attribute of the qptgrqup element specifies the label for a group of choices. 

In this example, we create a menu that allows the user to select which of seven software components to install The firs 
and second components are pre-selected but may be deselected by the user. The remaining components are not pre- 
selected. The size attribute states that the menu should only have 4 rows even though the user may select from among 
7 options. The other options should be made available through a scrolling mechanism. 

The select is followed by submit and reset buttons. 

<FORM action="http: //somesite. com/prog/component-select 11 method="post"> 
<P> 

<SELECT multiple size="4" name="component-select"> 

<OPTION selected value="Component_l_a">Component_K/OPTION> 

<OPTION selected value="Component_l_b M >Component_2</OPTION> 

<0PTI0N>Component_3</0PTI0N> 

<OPTION>Component_4</OPTION> 

<OPTION>Component_5</OPTION> 

<OPTION>Component_6</OPTION> 

<OPTION>Component_7</OPTION> 
</SELECT> 

<INPUT type= ,, submit" value="Send"><INPUT type^"reset "> 
</P> 
</FORM> 

Only selected options will be successful (using the control name "component-select"). Note that where the value 
attribute is set, it determines the control's initial value , otherwise it's the element's contents. 
In this example we use the qptgrqup element to group choices. The following markup: 

<FORM action= M http : //somesite . com/prog/ someprog" method="post "> 
<P> 

<SELECT name="ComOS"> 

<OPTGROUP label=*'PortMaster 3"> 

<OPTION label="3.7. 1" value="pm3_3 . 7 . l">PortMaster 3 with ComOS 3.7.1 

<OPTION label="3.7" value="pm3_3 . 7">PortMaster 3 with ComOS 3.7 

<OPTION label="3.5" value="pm3_3 . 5">PortMaster 3 with ComOS 3.5 
</OPTGROUP> 

<OPTGROUP label="PortMaster 2 M > 

<OPTION label= M 3.7" value="pm2_3 . 7">PortMaster 2 with ComOS 3.7 

<OPTION label="3.5" value="pm2_3 . 5">PortMaster 2 with ComOS 3.5 
</OPTGROUP> 

<OPTGROUP label="IRX"> 

<OPTION label="3.7R" value="IRX_3 . 7R">IRX with ComOS 3 . 7R 
<OPTION label="3.5R" value="IRX_3 . 5R">IRX with ComOS 3 . 5R 
</OPTGROUP> 
</SELECT> 
</FORM> 
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represents the following grouping: 

PortMaster 3 
3.7.1 
3.7 
3.5 

PortMaster 2 
3.7 
3.5 

IRX 

3.7R 
3.5R 



Visual user agents may allow users to select from option groups through a hierarchical menu or some other mechanism 
that reflects the structure of choices. 



A graphical user agent might render this as: 



This image shows a select element rendered as cascading menus. The top label of the menu displays the currently 
selected value (PortMaster 3, 3.7.1). The user has unfurled two cascading menus, but has not yet selected the new valu< 
(PortMaster 2, 3.7). Note that each cascading menu displays the label of an optgroup or option element. 



17.7 The textarea element 



<! ELEMENT TEXTAREA - - (# PCDATA) 
< ! ATTLIST TEXTAREA 



%attrs; 






name 


CDATA 


#IMPLIED 


rows 


NUMBER 


#REQUIRED 


cols 


NUMBER 


#REQUIRED 


disabled 


(disabled) 


#IMPLIED 


readonly 


(readonly) 


#IMPLIED 


tabindex 


NUMBER 


#IMPLIED 


accesskey 


%Character; 


#IMPLIED 


onf ocus 


%Script; 


#IMPLIED 


onblur 


%Script; 


#IMPLIED 


onselect 


%Script; 


#IMPLIED 


onchanqe 

^> 


%Script; 


#IMPLIED 



> 



— multi-line text field — > 

— %coreattrs , %i!8n , %events — 



— unavailable in this context — 

— position in tabbing order — 

— accessibility key character — 

— the element got the focus — 

— the element lost the focus — 

— some text was selected — 

— the element value was changed — 



Start tag: required, End tag: required 

Attribute definitions 

name = cdata [CI] 

This attribute assigns the control name. 
rows = number [CN] 

This attribute specifies the number of visible text lines. Users should be able to enter more lines than this, so usei 
agents should provide some means to scroll through the contents of the control when the contents extend beyond 
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the visible area. 



v ' cols = number |"CN] 

This attribute specifies the visible width in average character widths. Users should be able to enter longer lines 
than this, so user agents should provide some means to scroll through the contents of the control when the 
contents extend beyond the visible area. User agents may wrap visible text lines to keep long lines visible 
without the need for scrolling. 

Attributes defined elsewhere 

• id, class ( document-wide identifiers ) 

• lanq ( language information ), dir (text direction ) 

• title (element title ) 

• style (inline style information ) 

• readonly ( read-only input controls ) 

• disabled ( disabled input controls ) 

• tabindex ( tabbing navigation ) 

• onfocus , onblur , onselect . onchanqe , onclick , ondblclick , onmousedown , onmouseup . onmouseover , 
onmousemove, onmouseout, onkeypress . onkeydown , onkeyup ( intrinsic events ) 

The textarea element creates a multi-line text input control. User agents should use the contents of this element as the 
initial value of the control and should render this text initially. 

This example creates a textarea control that is 20 rows by 80 columns and contains two lines of text initially. The 
textarea is followed by submit and reset buttons. 

<FORM action="http : //somesite . com/prog/text-read" method="post ,f > 
<P> 

<TEXTAREA name="thetext" rows="20" cols="80"> 
First line of initial text. 
Second line of initial text. 
< / TEXTARE A> 

<INPUT type=" submit" value="Send ,, XINPUT type="reset"> 
</P> 



Setting the readonly attribute allows authors to display unmodifiable text in a textarea . This differs from using 
standard marked-up text in a document because the value of textarea is submitted with the form. 

17.8 The isindex element 

ISINDEX is deprecated . This element creates a single-line text input control. Authors should use the input element t< 
create text input control s. 

See the Transitional DTD for the formal definition. 

Attribute definitions 

prompt = text [CS] 

Deprecated. This attribute specifies a prompt string for the input field. 

Attributes defined elsewhere 

• id, class ( document-wide identifiers ) 
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</FORM> 




lang ( language information ! dir (text direction ) 

title (element title ) 

style ( inline style information ) 



The isindex element creates a single-line text input control that allows any number of characters. User agents may us* 
the value of the prompt attribute as a title for the prompt. 



(deprecated example 

The following isindex declaration: 

<ISINDEX prompt="Enter your search phrase: "> 

could be rewritten with input as follows: 

<FORM action^"..." method="post "> 

<P>Enter your search phrase: <INPUT type="text"></P> 
</FORM> 



Semantics of isindex. Currently, the semantics for isindex are only well-defined when the base URIfor the 
enclosing document is an HTTP URI. In practice, the input string is restricted to Latin- 1 as there is no mechanism 
for the URI to specify a different character set 

17.9 Labels 



Some form controls automatically have labels associated with them (press buttons) while most do not (text fields, 
checkboxes and radio buttons, and menus). 

For those controls that have implicit labels, user agents should use the value of the value attribute as the label string. 
The label element is used to specify labels for controls that do not have implicit labels, 
17.9.1 The label element 



<! ELEMENT LABEL ( %inline; )* - (LABEL) — form field label text — > 



< ! ATTLIST LABEL 



%attrs; 
for 

accesskey 

onfocus 

onblur 



— %coreattrs / %il8n , % events - 

IDREF #IMPLIED — matches field ID value — 

%Character; #IMPLIED — accessibility key character 

%Script; #IMPLIED — the element got the focus — 

%Script; #IMPLIED — the element lost the focus - 



Start tag: required, End tag: required 
Attribute definitions 
for = idreflCS] 

This attribute explicitly associates the label being defined with another control When present, the value of this 
attribute must be the same as the value of the id attribute of some other control in the same document. When 
absent, the label being defined is associated with the element's contents. 



Attributes defined elsewhere 



http ://www. w3 org/TR/1 998/REC-html40- 1 9980424/interact/forms.html 



6/23/0 



• id, class ( document-wide identifiers ) 

• lang (languafie information ), dir ( text direction ) 

• title ( element title ) 

• style ( inline style information ) 

• accesskev ( access keys ) 

• onfocus, onblur . onclick, ondblclick . onmousedown , onmouseup . onmouseover , onmousemove , onmouseout , 
onkeypress . onkeydown . onkeyup ( intrinsic events ) 

The label element may be used to attach information to controls. Each label element is associated with exactly one 
form control. 

The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as 
the value of the id attribute of the associated control element. More than one label may be associated with the same 
control by creating multiple references via the for attribute. 

This example creates a table that is used to align two text input controls and their associated labels. Each label is 
associated explicitly with one text input : 

<FORM action="..." method="post"> 
<TABLE> 
<TR> 

<TDXLABEL f or=" f name">First Name</LABEL> 
<TDXINPUT type="text" name="f irstname" id="fname"> 
<TR> 

<TDXLABEL f or="lname">Last Name</LABEL> 

<TDXINPUT type="text" name="lastname" id="lname"> 
</TABLE> 
</FORM> 

This example extends a previous example form to include label elements. 

<FORM action="http: //somesite . com/prog/adduser " method="post"> 
<P> 

<LABEL for="f irstname">First name: </LABEL> 

<INPUT type="text" id="f irstname "><BR> 
< LABEL for="lastname">Last name: </LABEL> 

<INPUT type="text" id="lastname M XBR> 
< LABEL for="email">email: </LABEL> 

<INPUT type="text" id="email"XBR> 
<INPUT type=" radio" name="sex" value="Male"> Male<BR> 
<INPUT type=" radio" name="sex" value=" Female" > Female<BR> 
<INPUT type="submit" value="Send"> <INPUT type="reset "> 
</P> 
</FORM> 

To associate a label with another control implicitly, the control element must be within the contents of the label 
element. In this case, the label may only contain one control element. The label itself may be positioned before or 
after the associated control. 

In this example, we implicitly associate two labels with two text input controls: 

<FORM action-". . . " method="post"> 
<P> 

<label> 

First Name 

<INPUT type="text" name="f irstname "> 
</LABEL> 
<LABEL> 
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<INPUT type="text n name= u lastname n > 

Last Name 
</LABEL> 
</P> 
</FORM> 



Note that this technique cannot be used when a table is being used for layout, with the label in one cell and its 
associated control in another cell. 

When a label element receives focus , it passes the focus on to its associated control. See the section below on access 
keys for examples. 

Labels may be rendered by user agents in a number of ways (e.g., visually, read by speech synthesizers, etc.) 

17.10 Adding structure to forms: the fieldset and legend elements 

<! — 

# PCDATA is to solve the mixed content problem, 
per specification only whitespace is allowed there! 
— > 

<! ELEMENT FIELDSET ( # PCDATA, LEGEND, ( %flow; ) *) — form control group — > 

< ! ATTLIST FIELDSET 

%attrs; — %coreattrs , %il8n, %events — 

> 

<! ELEMENT LEGEND ( %inline; ) * — fieldset legend — > 

<! ENTITY % LAlign " (top | bottom | left | right ) "> 

<! ATTLIST LEGEND 

%attrs; — %coreattrs / %i!8n , levents — 

accesskey %Character; #IMPLIED — accessibility key character -- 

> 



Start tag: required, End tag: required 
LEGEND Attribute definitions 



align = top | bottom | left I right [CI] 

Deprecated, This attribute specifies the position of the legend with respect to the fieldset. Possible values: 

• top : The legend is at the top of the fieldset. This is the default value. 

• bottom: The legend is at the bottom of the fieldset. 

• left : The legend is at the left side of the fieldset. 

• right : The legend is at the right side of the fieldset. 

Attributes defined elsewhere 



• id, class ( document-wide identifiers ) 

• lanq ( language information ), dir ( text direction ) 

• title ( element title ) 

• style (inline style information ) 

• accesskey (access keys ) 

• onclick, ondblclick , onmousedown . onmouseup . onmouseover , onmousemove , onmouseout . onkevpress 
onkeydown . onkeyup ( intrinsic events ) 



The fieldset element allows authors to group thematically related controls and labels. Grouping controls makes it 
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easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents 
and speech navigation for speech-oriented user agents. The proper use of this element makes documents more 
accessible. 

The legend element allows authors to assign a caption to a fieldset . The legend improves accessibility when the 
fieldset is rendered non-visually. 

In this example, we create a form that one might fill out at the doctor's office. It is divided into three sections: personal 
information, medical history, and current medication. Each section contains controls for inputting the appropriate 
information. 

<FORM action=". . . " method="post"> 
<P> 

<FIELDSET> 
<LEGEND>Personal Inf ormati on</ LEGEND > 

Last Name: <INPUT name="personal_lastname" type="text" tabindex="l"> 

First Name: <INPUT name="personal_f irstname" type="text" tabindex="2 "> 

Address: <INPUT name="personal_address" type="text" tabindex="3"> 

. . .more personal information. . . 
</FIELDSET> 
<FIELDSET> 

<LEGEND>Medical Hi s t o r y< / LEGEND > 

<INPUT name="history_illness" 
type=" checkbox" 

value="Smallpox n tabindex="20"> Smallpox 
<INPUT name="history_illness" 
type=" checkbox" 

value="Mumps" tabindex="21 "> Mumps 
<INPUT name="history_illness" 
type="checkbox" 

value="Dizziness" tabindex="22 "> Dizziness 
<INPUT name="history_illness" 
type="checkbox" 

value="Sneezing" tabindex="23"> Sneezing 
. . .more medical history. . . 
</FIELDSET> 
<FIELDSET> 
<LEGEND>Current Medication</LEGEND> 
Are you currently taking any medication? 
<INPUT name="medication_now" 
type="radio" 

value="Yes" tabindex="35">Yes 
<INPUT name="medication_now" 
type=" radio" 

value="No" tabindex="35">No 

If you are currently taking medication, please indicate 
it in the space below: 
<TEXTAREA name="current_medication" 
rows="20" cols="50" 
tabindex="40"> 
</TEXTAREA> 
</FIELDSET> 
</FORM> 

Note that in this example, we might improve the visual presentation of the form by aligning elements within each 
fieldset (with style sheets), adding color and font information (with style sheets), adding scripting (say, to only open 
the "current medication" text area if the user indicates he or she is currently on medication), etc. 
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4 

17.11 Giving focus to an element 



In an HTML document, an element must receive focus from the user in order to become active and perform its tasks. 
For example, users must activate a link specified by the a element in order to follow the specified link. Similarly, users 
must give a textarea focus in order to enter text into it. 

There are several ways to give focus to an element: 

• Designate the element with a pointing device. 

• Navigate from one element to the next with the keyboard. The document's author may define a tabbing order tha 
specifies the order in which elements will receive focus if the user navigates the document with the keyboard (se. 
tabbing navigation). Once selected, an element may be activated by some other key sequence. 

• Select an element through an access key (sometimes called "keyboard shortcut" or "keyboard accelerator"). 

17.11.1 Tabbing navigation 

Attribute definitions 
tabindex = number [CN] 

This attribute specifies the position of the current element in the tabbing order for the current document. This 
value must be a number between 0 and 32767. User agents should ignore leading zeros. 

The tabbing order defines the order in which elements will receive focus when navigated by the user via the keyboard. 
The tabbing order may include elements nested within other elements. 

Elements that may receive focus should be navigated by user agents according to the following rules: 

1 . Those elements that support the tabindex attribute and assign a positive value to it are navigated first. 
Navigation proceeds from the element with the lowest tabindex value to the element with the highest value. 
Values need not be sequential nor must they begin with any particular value. Elements that have identical 
tabindex values should be navigated in the order they appear in the character stream. 

2. Those elements that do not support the tabindex attribute or support it and assign it a value of "0" are navigated 
next. These elements are navigated in the order they appear in the character stream. 

3 . Elements that are disabled do not participate in the tabbing order. 

The following elements support the tabindex attribute: A, area , button , input , object, select , and textarea . 

In this example, the tabbing order will be the button , the input elements in order (note that "field 1 " and the button 
share the same tabindex, but "field 1" appears later in the character stream), and finally the link created by the a 
element. 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" 
"http: //www.w3. org/TR/REC-html40/strict ,dtd"> 
<HTML> 
<HEAD> 

<TITLE>A document with FORM</ TITLE > 

</HEAD> 

<BODY> 

. . . some text. . . 
<P>Go to the 

<A tabindex="10" href ="http : //www. w3 . org/">W3C Web site.</A> 
. . . some more. . . 

< BUT TON type="button M name="get-database" 

tabindex="l" onclick="get-database"> 
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*Get the current database. 
■ </BUTTON> 

. . . some more . . . 

<FORM action=". . . " method="post ,, > 

... • <P>. 

<INPUT tabindex="l" type="text" name="f ieldl"> 

<INPUT tabindex="2" type="text" name="f ield2 "> 

<INPUT tabindex="3" type=" submit" name="submit"> 

</P> 

</FORM> 

</BODY> 

</HTML> 

Tabbing keys. The actual key sequence that causes tabbing navigation or element activation depends on the 
configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a 
selected element). 

User agents may also define key sequences to navigate the tabbing order in reverse. When the end (or beginning) of 
the tabbing order is reached, user agents may circle back to the beginning (or end). 

17.11.2 Access keys 

Attribute definitions 

accesskey = character [CN] 

This attribute assigns an access key to an element. An access key is a single character from the document 
character set.Note. Authors should consider the input method of the expected reader when specifying an 
accesskey. 

Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element 
receives focus depends on the element. For example, when a user activates a link defined by the a element, the user 
agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio 
button. When the user activates a text field, it allows input, etc. 

The following elements support the accesskey attribute: a, area , button , input , label , and legend , and textarea . 

This example assigns the access key "U M to a label associated with an input control. Typing the access key gives focus 
to the label which in turn gives it to the associated control. The user may then enter text into the input area. 

<FORM action=" . . . " method="post"> 
<P> 

< LABEL for="fuser" accesskey="U"> 

User Name 

</LABEL> 

<INPUT type="text" name="user" id="fuser"> 

</P> 

</FORM> 

In this example, we assign an access key to a link defined by the a element. Typing this access key takes the user to 
another document, in this case, a table of contents. 

<PXA accesskey="C" 
rel="contents" 

href="http: //someplace. com/specification/contents . html"> 
Table of Contents</A> 

The invocation of access keys depends on the underlying system. For instance, on machines running MS Windows, on* 
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generally has to press the "alt" key in addition to the access key. On Apple systems, one generally has to press the 
* ' "cmd" 'key in addition to the access key. 

. -I!} e rendering of access keys depends on the user agent. We recommend that authors include the access key in label 
text or wherever the access key is to apply. User agents' should render the value of an access key in such a way as to 
emphasize its role and to distinguish it from other characters (e.g., by underlining it). 

17.12 Disabled and read-only controls 

In contexts where user input is either undesirable or irrelevant, it is important to be able to disable a control or render it 
read-only. For example, one may want to disable a form's submit button until the user has entered some required data. 
Similarly, an author may want to include a piece of read-only text that must be submitted as a value along with the 
form. The following sections describe disabled and read-only controls. 

17.12.1 Disabled controls 

Attribute definitions 

disabled [CI] 

When set for a form control, this boolean attribute disables the control for user input. 
When set, the disabled attribute has the following effects on an element: 

• Disabled controls do not receive focus . 

• Disabled controls are skipped in tabbing navigation . 

• Disabled controls cannot be successful . 

The following elements support the disabled attribute: button input , optgrqup . option, select , and textarea . 
This attribute is inherited but local declarations override the inherited value. 

How disabled elements are rendered depends on the user agent. For example, some user agents "gray out" disabled 
menu items, button labels, etc. 

In this example, the input element is disabled. Therefore, it cannot receive user input nor will its value be submitted 
with the form. 

<INPUT disabled name= n f red" value="stone"> 

Note. The only way to modify dynamically the value of the disabled attribute is through a script 

17.12.2 Read-only controls 

Attribute definitions 
readonly [CI] 

When set for a form control, this boolean attribute prohibits changes to the control. 
The readonly attribute specifies whether the control may be modified by the user. 
When set, the readonly attribute has the following effects on an element: 
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• Read-only elements receive focus but cannot be modified by the user. 

• Read-only elements are included in tabbing navigation . 

• Read-only elements may be successful . 

The following elements support the readonly attribute: input and textarea . 
How read-only elements are rendered depends on the user agent. 

Note. The only way to modify dynamically the value of the readonly attribute is through a script 

17.13 Form submission 

The following sections explain how user agents submit form data to form processing agents. 

17.13.1 Form submission method 

The method attribute of the form element specifies the HTTP method used to send the form to the processing agent. 
This attribute may take two values: 

• get : With the HTTP "get" method, the form data set is appended to the URI specified by the action attribute 
(with a question-mark ("?") as separator) and this new URI is sent to the processing agent. 

• post : With the HTTP "post" method, the form data set is included in the body of the form and sent to the 
processing agent. 

The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches 
have no visible side-effects and make ideal applications for the "get" method. 

If the service associated with the processing of a form causes side effects (for example, if the form modifies a database 
or subscription to a service), the "post" method should be used. 

Note. The "get" method restricts form data set values to ASCII characters Only the "post" method (with 
enctype="multipart/form-data") is specified to cover the entire [ISO10646] character set. 

17.13.2 Successful controls 

A successful control is "valid" for submission. Every successful control has its control name paired with its current 
value as part of the submitted form data set . A successful control must be defined within a form element and must hav€ 
a control name. 

However: 

• Controls that are disabled cannot be successful 

• If a form contains more than one submit button , only the activated submit button is successful. 

• All "on" checkboxes may be successful. 

• For radio buttons that share the same value of the name attribute, only the "on" radio button may be successful. 

• For menus, the control name is provided by a select element and values are provided by option elements. Onlj 
selected options may be successful. 

• The current value of a file select is a list of one or more file names. Upon submission of the form, the contents of 
each file are submitted with the rest of the form data. The file contents are packaged according to the form's 
content typ e 

• The current value of an object control is determined by the object's implementation. 
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If a control doesn't have a current value when the form is submitted, user agents are not required to treat it 
'successful control. 



Furthermore, user agents should not consider the following controls successful: 

• Reset buttons. 

• object elements whose declare attribute has been set. 

Hidden controls and controls that are not rendered because of style sheet settings may still be successful. For example: 

<FORM action^". . . " method="post"> 
<P> 

<INPUT type="password" style="display : none" 
name=" invisible-pas sword" 
value="mypassword"> 

</FORM> 



will still cause a value to be paired with the name "invisible-password" and submitted with the form. 

17.13.3 Processing form data 

When the user submits a form (e.g., by activating a submit button ), the user agent processes it as follows. 
Step one: Identify the successful controls 
Step two: Build a form data set 

A form data set is a sequence of control-name/current-value pairs constructed from successful controls 
Step three: Encode the form data set 

The form data set is then encoded according to the content type specified by the enctype attribute of the form element. 
Step four: Submit the encoded form data set 

Finally, the encoded data is sent to the processing agent designated by the action attribute using the protocol specified 
by the method attribute. 

This specification does not specify all valid submission methods or content types that may be used with forms. 
However, HTML 4.0 user agents must support the established conventions in the following cases: 

• If the method is "get" and the action is an HTTP URI, the user agent takes the value of action , appends a ? ■ 
to it, then appends the form data set encoded using the "application/x-www-form-urlencoded" content type . The 
user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes. 

• If the method is "post" and the action is an HTTP URI, the user agent conducts an HTTP "post" transaction 
using the value of the action attribute and a message created according to the content type specified by the 
enctype attribute. 

For any other value of action or method , behavior is unspecified. 

User agents should render the response from the HTTP "get" and "post" transactions. 

17.13.4 Form content types 
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the enctype attribute of the form element specifies the content type used to encode the form data set for submission tc 
* the server. User agents must support the content types listed below. Behavior for other content types is unspecified. 

Please also consult the section on escaping ampersands in URI attribute values . 

application/x-www-form-urlencoded 

This is the default content type. Forms submitted with this content type must be encoded as follows: 

1 . Control names and values are escaped. Space characters are replaced by * + ' , and then reserved characters are 
escaped as described in [RFC1738] . section 2.2: Non-alphanumeric characters are replaced by * %hh 1 , a percent 
sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as 
"CRLF" pairs (i.e., ^%od%oa'). 

2. The control names/values are listed in the order they appear in the document. The name is separated from the 
value by v = ' and name/value pairs are separated from each other by &\ 

multipart/form-data 

Note. Please consult [RFCl867] for additional information about file uploads, including backwards compatibility 
issues, the relationship between "multipart/form-data" and other content types, performance issues, etc. 

Please consult the appendix for information about security issues for forms . 

The content type "application/x-www-form-urlencoded" is inefficient for sending large quantities of binary data or text 
containing non-ASCII characters. The content type "multipart/form-data" should be used for submitting forms that 
contain files, non-ASCII data, and binary data. 

The content "multipart/form-data" follows the rules of all multipart MIME data streams as outlined in [RFC2045] . The 
definition of "multipart/form-data" is available at the [IANA] registry. 

A "multipart/form-data" message contains a series of parts, each representing a successful control . The parts are sent to 
the processing agent in the same order the corresponding controls appear in the document stream. Part boundaries 
should not occur in any of the data; how this is done lies outside the scope of this specification. 

As with all multipart MIME types, each part has an optional "Content-Type" header that defaults to "text/plain". User 
agents should supply the "Content-Type" header, accompanied by a "charset" parameter. 

Each part is expected to contain: 

1 . a "Content-Disposition" header whose value is "form-data". 

2. a name attribute specifying the control name of the corresponding control. Control names originally encoded in 
non-ASCII character sets may be encoded using the method outlined in [RFC2045] . 

Thus, for example, for a control named "mycontrol", the corresponding part would be specified: 

Content-Disposition: form-data; name^'mycontrol" 

As with all MIME transmissions, "CR LF" (i.e., * %od%oa') is used to separate lines of data. 

Each part may be encoded and the "Content-Transfer-Encoding" header supplied if the value of that part does not 
conform to the default (7BIT) encoding (see FRFC2045] . section 6) 
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, If the contents of a file are submitted with a form, the file input should be identified by the appropriate content type 
(e.g., ' apphcation/octet-stream"). If multiple files are to be returned as the result of a single form entry they should be 
returned as "multipart/mixed" embedded within the "multipart/form-data". 

The user agent should attempt to supply a file name for each submitted file, the file name may be specified with the 
filename" parameter of the 'Content-Disposition: form-data 1 header, or, in the case of multiple files, in a •Content- 
Disposition: file* header of the subpart. If the file name of the client's operating system is not in US-ASCII the file 
name might be approximated or encoded using the method of [RFC2045] . This is convenient for those cases where foi 
example, the uploaded files might contain references to each other (e.g., a TeX file and its " sty" auxiliary style 
description). 

The following example illustrates "multipart/form-data" encoding. Suppose we have the following form: 

<FORM action= M http: //server. dom/cgi/ handle" 
enctype="multipart/form-data" 
method="post f, > 

<P> 

What is your name? <INPUT type="text" name= "submit- name "><BR> 
What files are you sending? <INPUT type="f ile" name="f iles"XBR> 
<INPUT type=" submit" value="Send"> <INPUT type="reset "> 
</FORM> 



If the user enters "Larry" in the text input, and selects the text file "filel.txt", the user agent might send back the 
following data: 



Content-Type: multipart/form-data; boundary=AaB03x 
— AaB03x 

Content-Disposition: form-data; name=" submit -name" 

Larry 
— AaB03x 

Content-Disposition: form-data; name="f iles" ; f ilename="f ilel . txt " 
Content-Type : text/plain 

... contents of filel.txt ... 
— AaB03x — 



If the user selected a second (image) file "file2.gif the user agent might construct the parts as follows: 

Content-Type: multipart/ form-data; boundary=AaB03x 
— AaB03x 

Content-Disposition : form-data; name="submit-name" 

Larry 
— AaB03x 

Content-Disposition: form-data; name=" files" 
Content-Type : multipart/mixed; boundary=BbC04y 

— BbC04y 

Content-Disposition: attachment; f ilename="f ilel . txt" 
Content-Type : text/plain 

... contents of filel.txt ... 
— BbC04y 

Content-Disposition: attachment; f ilename="f ile2 . gif " 
Content-Type : image/gif 
Content-Transfer-Encoding : binary 
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:.. contents of file2.gif... 
— BbC04y — 
— AaB03x — 



previous next contents elements attributes index 
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